-
Notifications
You must be signed in to change notification settings - Fork 17
Bugfixes and new feature -- currently testing at home #40
base: master
Are you sure you want to change the base?
Conversation
Fix for sman591#17: confirmed fixed for fahrenheit units, TBD for celsius Fix for sman591#9: duplicate of sman591#17 Fix for sman591#16: requires user to choose in Homebridge UI since HomeKit cannot support custom characteristics (e.g. a switch for this) Fix for sman591#18 Fix for sman591#19 Plus, new feature: display filter cleaning status
Plus this file that should have been part of the last commit
Hey, thanks for contributing! Just glanced through everything and this looks reasonable. I'll try it out locally and give it a full review later -- feel free to convert to a full PR when you're ready. For the future, please split up each "major" contribution into its own PR. This should be ok for now, but it helps chunk up the review to each relevant change and benefits from automated changelog/release tooling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, looking good! Thanks for tackling these
src/characteristic/abstractSplitTemperatureThresholdCharacteristic.ts
Outdated
Show resolved
Hide resolved
this.device.updateCharacteristics( | ||
v.newValue === this.characteristic.AUTO ? true : false, | ||
this.platform.Characteristic.TargetHeaterCoolerState.UUID, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a clever way to accomplish what we need, but given a "cached" snapshot can be stale, this could inadvertently revert previous changes made in the UI since the last update interval.
Open to discussing a solution here, but it might be best in a separate PR. It seems like this is only necessary because changing the lockTemperature
value has implications on other characteristics; I wonder if we'd want some way to subscribe to changes that happen because of it, or mark characteristics as dependent on this flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would marking them dependent on each other do something in the UI? This is the best I could find given the way the Home app UI works. Regardless of the way we tackle this engineering-wise, do you know if we can make the UI more sensical in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Marking dependent" would be only an internal concept to this plugin; no native UI change. More as a way for characteristics to optionally subscribe to important changes such that we don't have to trigger a full cache-based refresh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Well, the "temperatureLocked" concept is trying to be that. So if we put aside the particular engineering approach to implement, how would you suggest we handle the UI if not a cache-based refresh?
handleSet?(value: CharacteristicValue, callback: CharacteristicSetCallback) { | ||
if (this.device.lockTemperature) { | ||
// updating from cache when we're locked puts things back to where they were, essentially preventing edits | ||
this.device.updateCharacteristics(true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be a potentially stale snapshot. I'd prefer we ignore the request or augment the handleSet / callback usage for this characteristic alone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, but then the user can change the temperature to something the AC won't accept, and the temperature will just revert back next refresh. Which could be 10 minutes from now. I didn't think that was great either...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I sort of think of it as one action -> one failure (ignored input) being better than (potentially) one action -> stale UI due to cache -> in-sync UI moments later. It's unfortunate that HomeKit doesn't support this set of modes appropriately but I think it could be more confusing to flash the user with a stale UI for this one case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. You should try disabling the "lockTemperature" flag and run the plugin to see what happens without it--it's not great. Basically you still get what you could be construed as a cached update: the temperature stays where the user set it, then snaps back to what the AC is actually at next refresh, potentially 10 minutes later. So my thinking here is that the user thinks they set the temperature to something preferable, then later realize the update didn't work. This would happen 100% of the time, whereas the cache being stale would be only when the connection between Thinq and the plugin is down, which I assumed was less than that. So TL;DR: this approach shows the correct state of the AC more often than any alternative.
I agree the real fix would be on the HomeKit side, but alas, can't find any fix there. Know anyone at Apple to ask what they would do in this case? Maybe there's something we don't know here...
src/platformAccessory.ts
Outdated
try { | ||
characteristic.handleUpdatedSnapshot(device.result.snapshot) | ||
characteristic.handleUpdatedSnapshot( | ||
<Unpacked<GetDeviceResponse['result']['snapshot']>>device, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is happening because let device = this.getDevice().snapshot
is somehow returning unknown
when it should be ... | unknown
-- not sure why that is, but I've pasted a suggestion above that should resolve this
src/platformAccessory.ts
Outdated
characteristic.handleUpdatedSnapshot( | ||
<Unpacked<GetDeviceResponse['result']['snapshot']>>device, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
characteristic.handleUpdatedSnapshot( | |
<Unpacked<GetDeviceResponse['result']['snapshot']>>device, | |
) | |
characteristic.handleUpdatedSnapshot(snapshot) |
@@ -134,4 +169,87 @@ export default abstract class AbstractCharacteristic< | |||
...parameters, | |||
) | |||
} | |||
|
|||
deviceUsesFahrenheit(): boolean { | |||
return this.device.getDevice().countryCode.startsWith('US') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused -- is this necessary? My understanding was both the LG and HomeKit APIs operate in Celsius, and it's just a matter of what HomeKit/LG display on screen that differs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary? Can't say with units that display celsius. So this was my attempt to limit my changes to only Fahrenheit units, and if we find it's needed with celsius units, we can change. But somebody else would have to test that (someone who has a celsius unit)
*/ | ||
getHomeKitCelsiusForLGAPICelsius(_celsius: number): number { | ||
if (!this.deviceUsesFahrenheit()) { | ||
return _celsius |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there harm in always performing the conversion? I believe both Celsius and Fahrenheit users will see these discrepancies due to rounding differences, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above
callback(error) | ||
|
||
// put UI back to where it was before | ||
callback(error, this.cachedState) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you merge this with line 148?
callback(error) | |
// put UI back to where it was before | |
callback(error, this.cachedState) | |
// put UI back to where it was before | |
callback(error, this.cachedState) |
@jeffmaki - Is this something that is still WIP / ongoing testing? |
I ran this branch to poke out differences. Noticed these in the logs.
|
# [1.12.0](v1.11.0...v1.12.0) (2021-04-20) ### Features * add filter life & condition (thanks [@jeffmaki](https://github.com/jeffmaki)!) ([6c94d0f](6c94d0f)), closes [#40](#40)
## [1.13.2](v1.13.1...v1.13.2) (2021-04-20) ### Bug Fixes * emit status on Homebridge boot (thanks [@jeffmaki](https://github.com/jeffmaki)!) ([97bfbc5](97bfbc5)), closes [#40](#40) [#18](#18)
Currently testing in my setup via my day-to-day usage. Feel free to join me? LMK if you have any thoughts/feedback?
Fix for #17: confirmed fixed for fahrenheit units, TBD for celsius
Fix for #9: duplicate of #17
Fix for #16: requires user to choose in Homebridge UI since HomeKit cannot support custom characteristics (e.g. a switch for this)
Fix for #18
Fix for #19
Plus, new feature: display filter cleaning status